In its raw form, video is a high volume form of data. Communication bandwidth in its variety of forms can be quickly consumed by the transmission of raw video information. Video compression techniques are known that attempt to retain the highest reproducibility of the original video while reducing the data volume required to transmit the information.
One form of video compression involves run length encoding in which patterns of pixels in a serial run of pixel information are identified, encoded, and transmitted by the code rather than by the individual pixels. U.S. patent application Ser. No. 10/260,534, entitled “Video Compression System,” filed on Oct. 1, 2002 (the '534 patent application) describes in some detail various kinds of run length encoding combined with some other types of novel pattern encoding. The entire contents of the '534 patent application are incorporated herein by reference. The algorithms referred to in the '534 patent application are sometimes referred to herein as “DVC compression.”
Another form of video compression divides video information into larger blocks of pixels and then transmits information about the block of pixels, rather than about the individual pixels themselves. In such systems, video received by a computer or other video source is usually loaded into a frame buffer. From there, blocks of information are compared to corresponding prior frame blocks to determine whether changes have occurred within the blocks. Video compression occurs because information about blocks without detected change need not be transmitted to the receiving end. Instead, the receiving end, employing the known compression algorithm used at the compression end, assumes that the pixels within a block remain the same from frame-to-frame until told otherwise by the compression end.
In an example block-by-block algorithm 8-bit video is captured and divided into 64×16 bit blocks of video for comparison with corresponding prior blocks. When video in a block is detected as changed, the information for that block is communicated to the receiving end. If no change is detected, no transmission occurs with respect to that block.
Such algorithms are presently employed in the computer environment to permit remote access to computer systems from non-proximate workstations. Keyboard, mouse and other (low volume) serial device information is communicated from the workstation to the remote computer via a communication link, and resultant (potentially high volume) video information is communicated back from the computer to the workstation via the communication link. Such systems and the methods they employ for such communications are by now well-known to the artisan.
In that computer environment, it is important that the computer video not “lag” behind the user's keyboard and mouse movements. It is unacceptable for a user to hit a key or move a mouse and see the results of that on the workstation monitor with any perceptible lag. In the remote computer environment, that means that the serial device information must communicated to the remote computer (usually a relatively easy task due to the low data volume), the computer's video processor must act on the information to create new video, and the computer's communication system must communicate the video back to the user—all before the user can detect lag between the moment the keyboard/mouse is used and the moment the resultant video is returned.
The block-by-block video encoding is one way that the video from the computer to the workstation is moved quickly back to the workstation such that no perceptible lag exists to the user. In the computer environment, many blocks within the computer screen of information may not change from frame to frame (such as on a desktop background, word processing document background, or other “inactive” location of the computer screen). With the block-by-block encoding, such blocks could be effectively ignored by the computer when sending the video information to the workstation because the workstation would assume that the blocks were not changed unless specifically told that they had been.
Block analysis occurred by evaluating pixel values within the block. One method provided a transmission of the block whenever a block change was detected, but a more improved method provided a number of pixels that had to change before the block transmission occurred. Thus, in the situation where blocks were 64×16, for example, a threshold number of six of the 1024 pixels had to change before the block was considered different enough to warrant the block transmission. The threshold gave the system room to accommodate a noise floor such that blocks could be ignored unless a change in the number of pixels exceeded a number that might be expected in a typical, noisy environment.
The block analysis was very effective in eliminating lag between keyboard/mouse entry and the corresponding video presentation. A problem developed, however, in which blocks would experience an important substantive pixel change that would go unreported to the workstation because the substantive pixel change did not cause the block to the exceed the noise threshold of, for example, six pixels changed. Examples of such occurrences included the tip of a mouse pointer moving through one or two pixels of a block. Because the number of pixels in the block that changed (the one or two pixels defining a piece of the mouse tip, or perhaps even three or four pixels once some noisiness was taken into consideration) failed to exceed the threshold, the block changes were unreported to the workstation. The effect was a lack of clarity in the mouse tip displayed at the workstation. The same situation occurred with respect to characters in a word processing document or on the desktop. If a two or three pixels of a changed character, such as the end of the hook in an “r” stretched into a block that was otherwise unchanged, the pixels would not be communicated and the end of the “r” would be deleted.
So, if the number of pixels changed within the block was set to one for the changes to be communicated, noise within the system would cause truly unchanged blocks to be communicated anyway. But, if the number of pixels changed within the block was set to more than one, potentially important pixel changes were lost.